This fix is acceptable, although I think adding a new PMF flag (PMF_NO_KNOCKBACK) is a bit risky, I would try to find another alternative. Therefore, modders are left with no alternatives for using these resources, because pm_flags is a networking variable that depends on the engine and is limited to 16 bits.

Have you ever tried with client->ps.pm_type == PM_DEAD or client->ps.eFlags & EF_DEAD in the conditional you tweaked in g_combat.c?

Hmm yes, this isn't great, I didn't know that this also affects the network struct.

Have you ever tried with client->ps.pm_type == PM_DEAD or client->ps.eFlags & EF_DEAD in the conditional you tweaked in g_combat.c?

I have checked, and this might have looked nicer, but would suffer from the same problem, because we set the flag in player_die, which means that the next pellet will check it and apply no knockback:

I will investigate applying knockback based on these

Closing in favor of #58

Couldn't you have continued same PR with more commits added to it? Any commits to your fork's branch that is linked on the PR will update the PR fwiw. Getting a lot of noti noise from all these minor PRs.

Couldn't you have continued same PR with more commits added to it?

I took a different approach, sometimes it's sensible to have a different MR in such a case so that it's easier to understand what happened reading the comments.

Getting a lot of noti noise from all these minor PRs.

Are you talking about just this PR and the one that supersedes it or about all my PRs? One giant PR with lots of changes is not easy to review and is not easy to merge, because one little thing that's not good enough will block the rest of the good changes. I though that's common to make PRs as small as reasonably possible.